[-empyre-] RE: Jim/Brendan: art/code transparency
Dear Brendan and Jim,
sorry I didn't respond sooner, in fact you both turned to aspects on work
transparency we formerly had neglected, I am very happy you did so. The lab
was mostly focused on the collaborative aspect of open source on an internal
level and did not take much care of the later transparency to the public
which is very important too!
I met the other curators of the backup.lounge|lab and we discussed the
issues you'll find below.
The major concern of my statement deals with the different importance of
transparency or the ability to "look under the hood" (you dont mind if I use
your words but translations like these are hard to come by if one has to
work in a foreign language, please don't be offended) within computer
science/open source and art.
> Open Source art would attempt...
{Just one quick notion at the beginning because I think the project is still
slightly misunderstood: loungelab does not deal with open source as art
(open source art). It believes the the theory of open source may work as a
model for artistic collaboration: Most of our artists -filmmakers, video
artists, media activists, designers, choreographers, video and sound
artists- do not deal with computer code!}
Brendan wrote:
> Some artists are very secretive of their techniques for fear of being
> copied or criticized. This is akin to proprietary software where you
> can see the result but you cannot look under the hood to see how it was
> made and how it works. Pride and economics are the main motivations I
> see for this sort of proprietary attitude. This also reinforces the
> romantic notions of the artist as a heroic mysterious genius.
Having a closer look at the development of electro-acoustic music in the
20th century we can observe that exactly this transparency of the artistic
works exist there (not in other forms of art). In most cases composers will
try to give an almost scientific explanation of how their works was created.
Talking about pride and economics here I am also not sure if these two
really can explain it properly. In my opinion the art of the 20th/21st
century has become intellectually complex in a way that we might sometimes
feel the strong demand to "look under the hood" in order not only to
criticise the art (as you mentioned) but also to really be able to grasp its
depth.
To return to the example, the interest in many electro-acoustic compositions
is based on understanding the structure behind them - still most composers
are aware that a piece of music/art also has to work on the aesthetic level
of reception without knowing. In my opinion music has found a way to
re-establish the genius (if the world needs it anyway) by the substitution
of objectivity (by scientific rules) vs. subjectivity.
Brendan wrote:
> Open Source art would attempt to document the techniques to create a
> work and the concepts that drive it. I think there's quite a lot of
> art that fits into this category already.
I really like to have some examples here just to show the differences that
various attempts will naturally have.
Jim wrote:
> And documented it well, both internally
> and in an essay about the code that macromedia later published on their site.
+
> Well, most people don't give a damn about the code or the essay about the
> code, they just visit Nio and enjoy it as art. And that's great.
+
> I also published the code because i would like to see the art of interactive
> audio for the web develop, would like to see new forms of music arise on the
> web. and this is a matter both of software development and artistic,
> conceptual evolution.
Did you only publish it for people who wanted to work with it and improve it
or continue the work? Or do you also think that examining the code is
necessary for the people in order to get an idea of the complexity of your
work?
Below there is my approach to different varianta:
When we try to conclude about the intentions to publish the structure behind
the result, we do encounter the major difference between code (art) and
other forms.
The documentation and publication of computer source code always thinks the
progress, the next programme, the improvement; the transparency in order
others can work on it(Jim: you described that for yourself). Of course it's
very useful to document the code here. But: Users who do not have the wish
to work on the code won't find it necessary to have a look at the source
code; if the software works satisfying there is no need to, and there is not
more appreciation from non-programmers if they understand the structure
below the surface (it's getting complicated instead of complex).
If a painter decides to publish his drafts, his annotations about the
picture (which we usually get in a third-person's point of view from an art
critic) it is not the same. Here, it is more likely the appreciation/respect
for what he did will change (+/-), while most people won't want to copy his
technique or improve it. Of course there is still copyism and surely the
need that styles of masters have been improved by their apprentices, anyway
transparency will generally affect understanding more than a modification.
I guess Jim's Nio project works at the border of code and art space that is
why I regard it to be very interesting to know about my question above.
-------
I feel we had a very fruitful discussion about the origin of sources which
is also not finished (thank you all so far!), please go on here, too.
If that will be appreciated by the other members of the list I would really
like the discussion turn to the aspect of transparency and the ways it can
be practised. Do we need to hang a text next to any art work if we want to
create open art?
Alexander Klosch, Carina Linge and I had a very interesting talk about the
topic and right now we are not too sure how much transparency on the work's
background an art/exhibition space can bear and what its use to the public
really can be (although we can see the necessarity for open source software
production!)
Thanks for responding, this will help us (and others?) a lot to design a
future lab!
Felix
This archive was generated by a fusion of
Pipermail 0.09 (Mailman edition) and
MHonArc 2.6.8.